The present invention relates to systems and methods for loading software. More specifically, the invention relates to systems and methods that are used by a program loader to manage the compatibility of software programs by detecting and processing version information.
In a computer system, software programs are frequently loaded into memory for subsequent execution. The loading process is typically performed by a program loader and may be initiated from different locations in the system including internal API calls or from applications or command line programs. Typically, a given program specifies the name of the program to be loaded. From this point, the loading process can be divided into two parts. The first is locating the program file to be loaded and the second is loading the program. To locate the program file, the loader searches through the file system according to a search path.
The search path is a consistent searching mechanism for finding one or more program files to be loaded. The search path may be defined according to the names of the directories to be searched when the loader retrieves a program. For efficiency, the search path may limit the amount of searching to a subset of the entire file system. In one conventional approach, the loader limits the search path to one or more eligibility lists. The eligibility lists are typically defined in terms of the file names and the order in which the entries within the directories are listed.
FIG. 1 illustrates a search path 100 suitable for illustrating a common searching methodology of conventional loading mechanisms. The path 100 includes libraries 102, 104 and 106. The libraries 102, 104 and 106 may represent separate directories, partitioned data sets or disk drives, for example. The libraries 102, 104 and 106 each contain a different version of program P and program Q. More specifically, the libraries 102, 104 and 106 contain versions P 1.3 108, P 1.2 112 and P 1.1 116 respectively. Similarly, the libraries 102, 104 and 106 contain versions Q 2.1 110, Q 2.2 114 and Q 2.3 118 respectively.
The loader would typically search down the search path 100 in the order in which the directories and entries were listed. The loader would select the first program of the correct name that it found. When two programs of the same name exist in the search path, the loader would select the first program of the correct name that it encountered. For example, in a search for program P where the loader searches from left to right through the search path 100, the loader would always select P 1.3 (108) for loading. Thus, in this example, the most recent version of the program would be loaded. Similarly, when looking to load program Q, the loader would always load Q 2.1 (110), which corresponds to the oldest version of the program. In this case, copies of the programs P and Q residing in the center 104 and rightmost libraries 106, or any other libraries located subsequent to 108 and 110 in the search path 100, would be ignored by the loader.
Many operating systems are developed and designed independently of the software applications running on them. In addition, a given software application is typically developed independently from other software applications running on the operating system, including those which it interacts with. Further, many operating systems and applications contain numerous subparts, which may be characterized as separate modules or programs. Together the modules or programs comprise the operating system or application. In the case of very large operating systems or applications, these modules should be developed somewhat independently of one another, by different groups of software engineers and programmers, for example. Software operating systems or applications are continually updated and released as new specific versions. As new versions of software operating systems and applications are released, they are loaded onto computer systems and are expected to be compatible with other software installed on the computer. In many cases, the new software requires particular versions of other programs that it interacts with. The loading and searching strategy of FIG. 1 is often inadequate since it always loads the first program according to name, regardless of compatibility with newly released software.
Modem computer systems typically run many different software applications. Accordingly, it is common for different versions of a program to be required by multiple software applications (e.g., clients) developed at varying dates. In an environment where different versions of a program are required, the above loading and searching strategy is also inadequate. This is because it will always locate the first program in the search path having desired name, regardless of version requirements for the different software applications.
Other searching methodologies may vary the searching order. This may be done by overriding the system wide eligibility lists. By way of example, the user may change the left to right order of the libraries 102, 104 and 106. Alternatively, the user may specify one or more substitute libraries to be used in place of the system wide eligibility lists. Despite these changes in the order in which the programs are encountered by the loader during searching, the changes do not address the inability to load anything but the first named program in the list encountered, regardless of version appropriateness to the software application being loaded. In addition, changing the system wide eligibility lists is not always possible or desirable to other functions requiring use of the eligibility lists. Further, the resulting override is often cumbersome, error prone and thus undesirable for support personnel.
Current searching methodology may include refining the eligibility lists in which the search progresses. More specifically, a search may be refined by a searching criteria. For example, in conventional UNIX loading, the eligibility lists are determined by one or more environment variables, i.e. PATH and LD_LIBRARY_PATH. While increasing searching efficiency, this searching methodology is still inadequate since it will retrieve the first version of the program encountered, regardless of version adequacy. In other words, alternate, and potentially better suited, versions of the program down the search path 100 are not selected.
The loading process may be invoked at run time or at any time prior to execution. In one conventional approach, an application is loaded at run time together with code that is shared between multiple applications. For example, a dynamic linked library (DLL) may be used. The DLL provides code for common resources and functions to be shared between multiple applications. The shared code may be responsible for common actions such as open, disconnect, etc. During loading, memory addresses for DLLs are established. Typically, accessing the shared code of the DLL requires an application to provide an established set of arguments. Once the proper arguments are entered, an address for the functions that the shared code is to perform is returned to the application.
Often there is no mechanism to check whether the proper arguments are being sent to the DLL. A new version of an application may supply different arguments than a previous version (e.g., a new version supplies two arguments for a particular function, while the previous version supplied four arguments in a particular order). As a result, the DLL may not be able to handle the new version; e.g., it may treat improper arguments as proper arguments. Regardless, the application will not receive the desired result from the DLL. In addition, because the problem is encountered at run time, the error is usually not detected until the application is executed, after considerable resources have already been expended.
Some large and complex software products such as network router operating systems have minor bugs that only show up in very limited environments. It has become increasingly common for specific customers to identify such bugs. The software vendor may issue bug fix in the form of a monolithic copy of the entire large software product. All users receiving this new version of the product must replace their previously installed product in its entirety. While the bug fix may solve the problem of some users, it may create problems for other users. This is leading some organizations to develop modular operating systems, which have various versions of individual modules comprising the overall operating system. In this manner, one module version designed to fix a bug observed in the context of one customer""s application, need not be distributed to other users, whose applications do not generate a problem with the existing software.
In view of the foregoing, it is clear that two additional capabilities, if added to the capabilities of most operating systems, would prove highly beneficial. The first is a technique for locating, not just a named program as is now done, but a particular version of a given program. The second is a technique for defining compatibility between different versioned applications.
The present invention provides systems and methods for enhanced software loading. When loading an application, version identification is included as part of the request. This allows a loader to request, access and load any level or version of a program or module required for execution regardless of its location in the search path. Once selected by the loader, a module or program may include specific compatibility information, which may be used to further determine whether it should be selected or passed over for another version of the same software. Using such information, a xe2x80x9cversion awarexe2x80x9d loader provides one way to ensure that loaded software modules are compatible with one another. This has a further benefit of allowing multiple versions of a software module to be accessed, loaded and stored conveniently within a given search path; a capability which greatly reduces operating system complexity. The version aware loader and loading techniques of the present invention may be conveniently implemented in an operating system or other loading software running on a wide variety of platforms, such as a personal computer or network router.
One aspect of the invention pertains to a method of loading into memory a software program having multiple modules, at least one of which is available in a plurality of versions identified by a set of version numbers. The method may be characterized by the following sequence: (a) identifying a module to be loaded as part of the software program, wherein the module is identified, at least in part, by an acceptable version number; (b) selecting the module based upon an acceptable version number from among the set of versions numbers of the module; and (c) loading the selected module into memory. Typically, the method will involve executing the selected module soon after it has been loaded into memory. If no module was found that corresponded to an acceptable version number, the method may inform the user of this failure.
Typically, the plurality set of versions of the module share a common name, each of which has a unique version number. Often, modules that potentially satisfy the load criteria will first be located by using the common name to search for the module in the specified search path. Each potential candidate will then subjected to version checking to ensure its acceptability. The selected module will be the first module found in the path that has the common name and the acceptable version number. Thus, it may be necessary to examine several potential candidate-modules in order to find one that has an acceptable version number.
In some embodiments, the acceptable version number set is identified by a Boolean expression. In one example, such Boolean expression may specify a group of version numbers that are greater than or equal to a particular version number of the module. To account for the possibility that an open ended Boolean expression may specify a range of versions that include members that are not backward compatible, the method may require confirming that the selected module is compatible with any modules that call it.
Another aspect of the invention pertains to computer program products including a machine readable medium which provides program instructions for implementing a method as described above. Any of the methods of this invention may be represented as program instructions that can be provided on such computer readable media.
Yet another aspect of the invention pertains to a versioned software module capable of being loaded with various combinations of other modules. The software module may be characterized by the following features: (a) a name in common with at least one module not included in the software program; and (b) a compatibility vector. The module and the at least one module not included in the software program differ from one another by a version identification included in the module (e.g., in a header of the module). The compatibility vector includes a set of entries. Each entry in the set includes (i) the name of a component containing a called module that is called by the versioned software module during execution, and (ii) a compatible version number or group of version numbers for the component containing the called module. The compatible version number or the group of version numbers may be expressed as a logical range of version numbers (e.g., as a Boolean expression). The versioned software module may also include indicia of backward incompatibility with other modules that may call the versioned software module.
Yet another aspect of the invention pertains to a computer system capable of loading and executing software. The computer system may be characterized by the following features: (a) a memory which temporarily stores software modules for execution; (b) a processor which executes loaded software modules; and (c) a loader which loads said software modules into the memory. The loader selects at least some software modules for loading based on acceptable version numbers when such modules are available in a plurality of versions identified by a set of version numbers. Typically, though not necessarily, the computer system will include a second memory, which persistently stores the software modules. The loader loads the software modules into memory from the second memory prior to execution. In many ways, the loader acts in accordance with the method described above. For example, the loader may consider a compatibility vector of a software module when selecting modules for loading.
The invention relates in accordance with another embodiment to an operating system capable of running with multiple versions of a module. The operating system includes a first numbered version of the module. The operating system also includes the second through the nth numbered versions of the module, wherein the first numbered version of the module and and any number of the second through the nth versions of the module are loaded independently and are used or are available for use by the system in a concurrent fashion.
The invention relates in accordance with a further embodiment to a method managing a software environment, the software environment including a plurality of software programs, the plurality of software programs including a set of modules that share a common name, but which differ by version as defined in their different version numbers. The method includes loading a first numbered version of the module having a common name for a first program. The method also includes loading a second through the nth numbered version of the module having a common name for a second through nth programs. The method further includes running the first numbered version of the module having a common name. The method additionally includes running the second numbered version of the module having a common name.